Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Print dependencies in uv pip list. #10886

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tjni
Copy link

@tjni tjni commented Jan 23, 2025

Summary

This is controlled by the --requires and --required-by flags and only works when the output format is JSON.

This addresses part of #4711, but I agree with #4711 (comment) that it belongs in uv pip list instead of uv pip tree. A few notes about this:

  1. I picked --requires and --required-by to match the Requires and Required-By fields that appear in the output of uv pip show.
  2. I decided to return the dependencies as objects with a single field called name. This leaves the door open to add more fields to each dependency in the future, such as installed version and requested versions.

I'm hoping to get some early feedback on this PR to test the temperature of this approach, before I proceed. The remaining work as I see it currently includes:

  • Add tests for this feature.
  • Add documentation for this feature.
  • Better error messages (e.g. if used with the default column format, perhaps suggest uv pip tree instead).
  • Any code review suggestions (I'm a Rust novice).

Test Plan

This is controlled by the --requires and --required-by flags and only
works when the output format is JSON.
@Gankra Gankra self-requested a review January 23, 2025 14:22
@tjni
Copy link
Author

tjni commented Jan 23, 2025

As I was doing more research about this, I noticed that pypa/pip#11097 is prior art, where incorporating arbitrary metadata into the output of pip list was rejected in favor eventually of pip inspect. This brings up the question to us too about where to draw the line about what to include under this command. I'm not sure.

@tjni
Copy link
Author

tjni commented Jan 31, 2025

Hi team, wondering if you’ve had a chance to think about if this is the right form factor for exposing this information. Thank you!

Copy link
Contributor

@Gankra Gankra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for the delay! I think the basic idea looks reasonable, I mostly have a few quibbles about the structure.

Comment on lines +1981 to +1982
#[arg(long, overrides_with("no_requires"))]
pub requires: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the semantics you've implemented this seems like this should also include conflicts_with = "required_by".

Comment on lines +1984 to +1985
#[arg(long, overrides_with("requires"), hide = true)]
pub no_requires: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm what's the usecase for having this opt out flag too?

@@ -150,6 +160,47 @@ pub(crate) async fn pip_list(
results
};

let requires_map = if requires || required_by {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to structure this as

let requires_map = requires.then(|| { ... });
let required_by_map = required_by.then(|| { ... });

As-is it's weird to have this shared variable for two conceptually independent results just because they happen to have the same type. It's also not clear to me that these need to be mutually exclusive outputs? (And if that's the case, ignore the note above about the cli conflicts_with)

@zanieb
Copy link
Member

zanieb commented Feb 3, 2025

I'm also wondering about how this fits into our CLI... like uv pip list has flags to show dependencies but this overlaps with uv tree right? There are also requests for things like uv license (#10292) to show license information. I'm sort of in favor of uv inspect / uv show to see metadata about packages instead?

@zanieb
Copy link
Member

zanieb commented Feb 3, 2025

I guess more broadly it's unclear if we should have uv list which is an alternative to uv tree somehow? I find it confusing already that we have both pip tree and pip list commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants